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Abstract of DE1 992461 0 

The procedure is carried out by modules which are called and processed 
one after the other. Common components are used as stand-alone 
modules in the set-up procedure. The common component contains 
information on how often it is called by other set-up programs to install or 
de-install. The common component is automatically de-installed if it is 
called by the last product installation to de-install. The modules are 
arranged in a hierarchy with a top module having a graphic user interface 
and sub-modules without graphic user interfaces. The modules are 
processed according to the hierarchy. 
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Aufruf als Unlermodul 



Die folgenden Angaben sind den vom Anmelder eingereichten Unterlagen entnommen 

Prufungsantrag gem. § 44 PatG ist gestellt 
@ Setup-Verfahren 

(g) Es wird ein Setup-Verfahren zum Installieren und Dein- 
stallieren von Software-Produkten oder -produktfamilien 
bereitgestellt, die wenigstens eine Komponente gemein- 
sam nutzen, wobei die gemeinsame Komponente bei der 
Installation der Produkte instaMiert oder einem Update 
unterworfen und bei der Deinstallation deinstalliert wird, 
wenn sie nicht mehr benotigt wird. Das Setup-Verfahren 
wird durch Module ausgefuhrt, die nacheinander aufge- 
rufen und abgearbeitet werden. Die gemeinsamen Kom- 
ponenten werden als eigenstandige Module innerhalb 
des Setup-Verfahrens ausgefuhrt, und dazu wird ein eige- 
nes Installationsprogramm und Deinstallationspro- 
gramm ausgefuhrt. 
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oben beschriebenen Nachteilen. Werden Anderungen am Installationsprogramm durchgefuhrt, dann kann auf einfache 
Weise das geanderte Modul ausgetauscht werden. Durchzufiihrende Tests miissen nicht so umfangreich gemachi werden, 
da nur die einzelnen Module und deren Zusammenspiel getestet werden muB. 

Die unterschiedlichen Abhangigkeiten die dadurch entstanden sind, daB je nach Benutzerauswahl mehrere gemein- 
same Komponenten installiert werden mussen, sind nun dadurch gelost, daB eine gemeinsame Komponente von der ei- 5 
gentlichen Produktinstallation gezielt installiert und deinstalliert wird. 

Bei dem erfindungsgemaBen Verfahren ist es moglich, sowohl die eigentliche Produktinstallation, als auch die damit 
installierten Komponenten als Modul zu implementieren. Somit werden die Produktinstallationen als auch die gemein- 
samen Komponenten zu gleichwertigen Modulen. Sie unterscheiden sich nur dadurch, daB die Produktinstallation zu ei- 
nem Modul mit Benutzeroberflache wird, wahrend eine Komponente als Modul ohne Benutzeroberflache aufgerufen 10 
wird. Im Allgemeinen wird das Modul ohne Benutzeroberflache (Untermodul) immer von einem Modul mit Benutzer- 
oberflache (Obermodul) aufgerufen. Zwischen den einzelnen Modulen mufi dazu wahrend der Installation kommuniziert 
werden. Wenn die Art der Kommunikation festgelegt ist, dann konnen die Module aus verschiedenen ausfuhrbaren Pro- 
grammen bestehen. 

Ein Installationsprogramm kann beispielsweise mit Wise, InstallShield, C++ oder dergleichen erstellt werden. MuB 15 
ein Modul geandert werden, dann kann es auch in einer anderen 'Trogrammiersprache" entwickelt werden und kann vol- 
lig transparent wieder eingefugt werden, da die Funktionalitat nach auBen gleichbleibt. 

Durch die Art der Implementierung wird auch die Moglichkeit. geschaffen, daB ein Modul sowohl mit Benutzerober- 
flache als auch ohne installiert werden kann. Damit ist es fur einen Administrator moglich, das Installationsprogramm 
auf einem Computer im Netzwerk zur Verfugung zu stellen und durch entsprechende MaBnahrnen (beispielsweise Login- 20 
skript) auf den Rechnern (Clients) zu installieren, ohne daB der Benutzer dies merkt. 

Fehlende oder nicht benotigte Produktinstallationen oder Teilkomponenten konnen ohne besonderen Aufwand weg- 
gelassen oder hinzugefugt werden. 

Eine vorteilhafte Ausgestaltung des erfindungsgemaBen Verfahrens ist dadurch gekennzeichnet, daB in der gemeinsa- 
men Komponenten festgestellt und gespeichert wird, wie oft sie von anderen Setup-Programmen zur Installation bzw. 25 
Deinstallation aufgerufen wurde, und daB die gemeinsame Komponente dann aulomalisch deinstalhert wird, wenn sie 
von der Ictztcn Produktinstallation zur Deinstallation aufgerufen wird, die die gemeinsame. Komponente noch benutzt 
hat. 

Jede Komponente ist im Zuge der Modularisierung so entwickelt, daB sie selbstandig erkennt, wie oft sie von unter- 
schiedlichen Installationsprogrammen installiert, das heiBt aufgerufen wurde, kann sie auch erkennen, wann die eigent- 30 
liche Deinstallation der Komponente durchgefuhrt werden muB. Eine Komponente deinstalliert sich genau dann, wenn 
sie von der letzten Produktinstallation zur Deinstallation aufgerufen wird, die diese Komponente noch benutzt. Durch die 
Art der Implementierung ist sichergestellt, daB die Komponente auch noch zu fruheren installierten Versionen kompati- 
bel ist und diese entsprechend deinstalliert werden konnen. 

Eine vorteilhafte Ausgestaltung des erfindungsgemaBen Verfahrens ist dadurch gekennzeichnet, daB die Module in 35 
eine Hierarchie aus wenigstens einem Obermodul mit Benutzeroberflache und Untermodulen ohne Benutzeroberflache 
eingegliedert werden, und daB die Module entsprechend der Hierarchie abgearbeitet werden. Damit wird erreicht, daB 
das Setup- Verfahren von der Installation eines Modules zur Installation des nachstens Moduls erst dann ubergeht, wenn 
die Installation des vorhergehenden Moduls abgeschlossen ist, so daB es keine Uberschneidungen gibt. 

Eine weitere vorteilhafte Ausgestaltung des erfindungsgemaBen Verfahrens ist dadurch gekennzeichnet, daB beim 40 
Hinzufiigen eines neuen Obermoduls ein bisheriges Obermodul als Untermodul aufgerufen wird, und daB vorzugs weise 
das neue Obermodul die gesamte Benutzeroberflache beinhaltet. 

Ein bisheriges Obermodul mit Benutzeroberflache kann somit auch als Untermodul aufgerufen werden. In diesem Fall 
muB ein neues Obermodul exisderen, evtl. ein Modul zur Installation der gesamten Produktfamilie oder noch hoher an- 
gesiedelt und nicht nur der einzelnen Produkte. Dieses neue Obermodul kann dann die komplette Benutzeroberflache be- 45 
inhalten. Es ruft die bisherigen Obermodule als Untermodul auf, die dann keine Benutzeroberflache mehr anzeigen. Die 
Ober-/Untermodule konnen dann wie bisher die benotigten Untermodule aufrufen. Zusatzlich konnen vom neuen Ober- 
modul auch die bisher existierenden Untermodule aufgerufen werden. 

Man spricht von einem Obermodul, wenn es eine Benutzeroberflache besitzt und als eigenstandiges Installauonspro- 
gramm aufgerufen werden kann. En Obermodul generiert immer einen Uninstalistring in der Registry, damit es uber die 50 
Systemsteuerung deinstalliert werden kann. Wird ein Obermodul als Untermodul (Parameter/Launcher in der Komman- 
dozeile) aufgerufen, dann muB es dessen Funktionalitat vollstandig erfullen. Wird ein Obermodul von einem weiteren 
Obermodul als Untermodul aufgerufen, dann handelt es sich bei dem neuen Obermodul meist um das Installationspro- 
gramm fur die gesamte Produktfamilie. 

Eine weitere vorteilhaft Ausgestaltung des erfindungsgemaBen Verfahrens ist dadurch gekennzeichnet, daB die Hier- 55 
archie bzw. die Aufrufreihenfolge in einer Anweisungstabelle festgehalten wird, die vorzugsweise auBerhalb der Module 
angelegt wird. 

Durch eine optional auBerhalb der Module liegende Anweisungstabelle konnen die Module erkennen, auf welcher Po- 
sition einer vollig freien Modulhierarchie sie stehen. Wird die Anweisungstabelle geandert, dann werden die Module in 
anderen Aufrufreihenfolgen (andere Hierarchie) aufgerufen, was unter Umst.anden die Funktionalitat. eines Produktes 60 
oder der gesamten Produktfamilie entscheidend andert. Uber eine solche Modulhierarchie mit extemer Anweisungsta- 
belle konnen Produkte ohne wesentlichen Aufwand in verschiedene Produktfamilien integriert werde, auch in solche, in 
denen der Einsatz eines bestimmten Produktes bisher nicht vorgesehen war. Zudem konnen bisher bestehende Produkt- 
installationen neue zusatzliche Funktionen ohne Anderung des Installationsprogrammes installieren, wenn ein neues 
Modul hinzugefugt und die Anweisungstabelle entsprechend geandert wird. 65 

Zur Kommunikation wird im Allgemeinen die Kommandozeile, eine INI-Datei, die Registry oder andere Moglichkei- 
ten des Datenaustausches verwendet. Die Anweisungstabelle kann optional sein und ist im Allgemeinen als INI-Datei 
oder Registry-Tabelle oder jede andere Moglichkeit der Datenhaltung abgespeichert. 

3 
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Die Installation smodule sind fur die Durchfuhrung der Installation an sich verantwortlich. In diesen Modulen werden 
beispielsweise Dateien kopiert, Treiber installiert und Registry-Eintrage vorgenommen. Ein Installationsmodul kann 
uber eine Benutzeroberflache verfugen, wenn Interaktionen mil dem Benutzer notwendig sind. Wird die InstaUation von 
einem Administrator liber das Netzwerk durchgefuhrt, ohne daS der Benutzer dies merken soli, dann verwendet das In- 
stallationsprogramm automatisch eine Auftragsdatei, die beschreibt, wie zu instaUieren ist. 

Eine weitere vorteilhafte Ausgestaltung des erfindungsgemaBen Setup- Verfahrens ist dadurch gekennzeichnet, daB 
beim Start einer Installation gepriift wird, ob ein Zahlerstand in einem Modulcounter vorhanden ist, daB, wenn kein Zah- 
lerstand in dem Modulcounter vorhanden ist, und es sich damit urn eine NeuinstaUation handelt, der Zahlerstand auf 1 
gesetzt, ein Uninstallstring gesetzt und ein Display Name erzeugt wird, daB, wenn ein Zahlerstand in dem Modulzahler 
vorhanden ist, ein Uninstallstring erzeugt und der Zahlerstand des Modulcounters erhoht wird, wenn das Modul zum er- 
sten Mai als Obermodul aufgerufen wurde, und daB dann die Installation der gemcinsamen Komponente durchgefuhrt 
wird. Hierbei handelt es sich urn ein vorteilhaftes Verfahren, mit dem in dem Modul festgestellt werden kann, wie oft die 
gemeinsame Komponente installiert werden soil. 

Eine weitere vorteilhafte Ausgestaltung des erfindungsgemaBen Setup- Verfahrens ist dadurch gekennzeichnet, daB bei 
der Installation einer gemeinsamen Komponente durch ein Modul, die in Form eines Untermoduls installiert wird, ge- 
priift wird, ob das Untermodul (gemeinsame Komponente) bereits installiert war, daB, wenn der Untermodul bereits in- 
stalliert war und kein Upgrade voriiegt, der Zahlerstand des Modulcounters des Untermoduls erhoht, das Untermodul als 
Client eingetragen, die Deinstallationsroutine vermerkt und die Installation an dem Untermodul durchgefuhrt. wird, und 
daB wenn das Untermodul noch nicht installiert war, der Zahlerstand des Modulcounters des Untermoduls um den Wert 
des eigenen Modulcounters erhoht, das Update Rag geloscht, das Untermodul als Client eingetragen, die Deinstallati- 
onsroutine vermerkt und die Installation des Untermoduls durchgefuhrt wird. Auf diese Weise wird der Zahlerstand in 
dem Untermodul immer auf den neuesten Stand gebracht, d. h. bei jeder Neuinstallation upgedatet. 

Eine weitere vorteilhafte Ausgestaltung des erfindungsgemaBen Setup- Verfahrens ist dadurch gekennzeichnet, daB bei 
einer Deinstallation gepriift wird, ob andere Module aufgerufen werden sollen, daB, wenn andere Module aufgeruten 
werden sollen, die Module zur Deinstallation aufgerufen werden, daB, wenn im Client noch ein Zahlerstand im Modul- 
counter vorhanden ist, ein weiteres Modul aufgerufen wird und daB, wenn im Client kein Zahlerstand im Modulcounter 
vorhanden ist, der Clicntvcrmcrk geloscht und die Dcinstalladonsroutinc fortgesctzt wird. Mit dicscr Vcrfahrcnswcisc ist 
sichergestelltJdaB die gemeinsame Komponente erst dann geloscht wird, wenn sie von keinem Modul mehr gebraucht. 
wird, aber auch nur dann. 

SchlieBlich ist eine weitere vorteilhafte Ausgestaltung des erfindungsgemaBen Setup- Verfahrens dadurch gekenn- 
zeichnet daB, wenn der Zahlerstand im Modulcounter gleich "l" ist, gepriift wird, ob es einen Zahlerstand in einem Sha- 
red-Counter gibt, daB. wenn ja eine Deinstallation durchgefuhrt wird, die Files geloscht werden und der Shared-Counter 
erniedrigt wird, daB, wenn nein alle Dateien deinstalliert und alle Eintrage geloscht werden, und daB, wenn der Zahler- 
stand im Modulcounter ungleich n 1 " ist, der Zahlerstand im Modulcounter um " 1 " erniedrigt und der Modul deinstalliert 
35 wird 

Ausfuhrungsbeispiele der Erfindung werden nun anhand der beiliegenden Zeichnungen beschrieben. Es zeigen: 
Fig 1 ein Blockdiagramm einer Hierarchic, bestehend aus einem Obermodul und mehreren Untermodulen; 
Fig! 2 ein Blockdiagramm einer Hierarchie, bestehend aus zwei Obermodulen mit Benutzeroberflache und mehreren 
Untermodulen; 

40 Fig, 3 ein Ablaufdiagramm fur die InstaUation eines Modules; 

Fig. 4 ein Ablaufdiagramm fur die Installation eines Untermoduls; 
Fig. 5 ein Ablaufdiagramm einer Deinstallation eines Moduls; 

Fig. 6 ein Beispiel einer hierarchischen Struktur des Setup- Verfahrens implementiert mit einem Wise-Installer; und 
Fig 7 ein Blockdiagramm fur die Deinstallation bei dem Wise-Installer 

In Fig 1 ist ein Obermodul mit Benutzeroberflache (GUI = Graphical User Information). Entsprechend der Hierarchie 
werden von dem Obermodul der Untermodule 1 und von diesem die Untermodule 4 und 5 aufgerufen. Von dem Ober- 
modul wird auch das Untermodul 2 und das Untermodul 3 entsprechend der Hierarchie aufgerufen. 

In Fig. 2 ist die Variante gezeigt, bei der ein Obermodul als Untermodul aufgerufen, wobei es sich dann bei dem neuen 
Obermodul meist um das Installationsprogramm fur die gesamte Produktfamilie handelt. 

Man spricht von einem Untermodul, wenn ein Modul keine Benutzeroberflache besitzt und nur im Silent-Mode (bei 
Wise mit Kommandozeilenparameter /S) aufgerufen werden kann. Ein Untermodul wird immer mit dem Parameter 
/Launcher in der Kommandozeile aufgerufen. 

Die Anforderungen, die ein Modul hat, bestehen darin, daB das Installationsmodul wissen muB, ob em Upgrade (In- 
staUation mit Beibehalten von gewissen Einstellungen der vorher instaUierten Version), eine Installation (komplett neue 
Installation) oder eine Deinstallation durchzufuhren ist, ob die Installation ohne Benutzerinteraktion durchgefuhrt wer- 
den soU welche InstaUationsoptionen zu wahlen sind (Eingabe uber Benutzeroberflache oder Auftragsdatei), welche 
Komponenten die in diesem Modul behandelt werden, zu instaUieren sind. Das Installationsprogramm muB ferner wis- 
sen, welche Untermodule zu instaUieren sind, und es fuhrt Buch uber den aktuellen Stand seines Ablaufs und ermoglicht 
somit das Wiederaufsetzen einer halbfertigen InstaUation. 

Eine rnodulare Installation besteht. ublicherweise aus einem oder mehreren Obermodulen, Untermodulen, TNI Dateien, 
die fur die Kommunikation zwischen Obermodulen und Untermodulen und zum Abwickeln der InstaUation ohne Benut- 
zerinteraktion verantwortlich sind. . 

Das Obermodul fuhrt gewohnhch alle Benutzerabfragen durch, die notig sind, um einen InstaUationsdurchlaut voU- 
standig zu derinieren. Das InstaUationsprogramm des Obermoduls kann dabei in verschiedenen Modi ablaufen. Im Ad- 
mini stratormodus erfolgt ein Aufruf zum Schreiben einer Auftragsdatei, oder im Benutzermodus, bei dem eine Benutz- 
eroberflache vorhanden ist und der immer dann ablauft, wenn keine Auftragsdatei vorhanden ist, oder im NetzinstaUati- 
onsmodus ohne Benutzeroberflache immer dann, wenn die Auftragsdatei gefunden wird. 

Im Administratormodus wird die Benutzeroberflache der InstaUation dazu verwendet durch einen Administrator eine 
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Auftragsdatei fur die Installation smodule zu erstellen. Zusatzlich wird in diesem Modus erfragt, wie das Resultat der In- 
stallation festzuhalten ist (beispielsweise Ereignisanzeige unter NT, Pfad und Name fur die Ergebnisdatei; SMS . . .). 
Wenn die Auftragsdatei erstellt ist, ist der Administratormodus beendet, das heiBt es wird keine Installation im eigentli- 
chen Sinne durchgefuhrt. sondern nur die Auftragsdatei geschrieben. 

Im Benutzermodus wird das Programm vom Benutzer gestartet und alle Abfragen werden vom Benutzer beantwortet 
(Benutzeroberflache) und daraufhin wird die eigentliche Installauon durchgefuhrt. 

Im Netzinstallationsmodus wird die Installation aufgerufen und verwendet automatisch eine im Administratormodus 
erstellte Auftragsdatei, die vorzugsweise im gleichen Verzeichnis liegt, in dem die Installation selber liegt. Dem Benut- 
zer wird beispielsweise im Login Skript ein Start der Installation eingestellt. Die automatische Verwendung des Netzin- 
stalltionsmodus beim Vorliegen der Auftragsdatei muB automatisch erfolgen. Ein Benutzer der die Installation von sich 
aus startet ist somit ebenfalls gezwungen, den vordefinierten Weg der Installation durchzufiihren. Der Netzinstallations- 
modus wird immer als Unattended-Installation oder Silent-Installation durchgefuhrt. 

Technisch gesehen besteht ein Obermodul aus drei Hauptkomponenten, namlich der graphischen Benutzeroberflache 
(Was muB vom Benutzer/Administrator abgefragt werden?), der Starterkomponente (Welche Untermodule sind zu star- 
ten?)und dem Checker (sind alle Bedingungen fur die Untermodule erfullt?) 

Das Obermodul liest Daten aus der Datei Modulbeschreibungdatei, schreibt im Benutzer- oder Netzinstallationsmodul 
seinen Fortgang in die Datei Statusdatei und erzeugt im Benutzer- oder Administratormodus die Datei Auftragsdatei. Das 
Ziel ist, dafrdas Obermodul aus den Eintragen in der Modulbschreibungdatei seine Auswahldialoge aufbauen und erken- 
nen kann, welche Untermodule aufzurufen sind. Untermodule die eigene zusatzliche Abfragen benotigen, konnen dies in 
Form von Bibliotheken (DLL's) mit Benutzerdialogen tun, die in das Obermodul eingebunden werden. 

Die graphische Benutzeroberflache mit "silent" Option ermoglichU daB alle Installationsoptionen vom Benutzer oder 
Administrator eingegeben werden konnen. Wird die Installation "normal" gestartet, dann kann der Benutzer verschie- 
dene Optionen eingeben und die Installation durchfuhren. Wird die Installauon im Administratormodus gestartet, dann 
wird nur die Benutzeroberflache abgearbeitet und anschlieBend die Installation abgebrochen. Der Administrator kann da- 
bei alle erforderkchen Opuonen eingeben und eine Auftragsdatei erstellen. 

Die Starterkomponente des Obennoduls ("Launcher") fuhrt generell eine Installation und/oder eine Deinstallauon 
durch. Bei der Dcinstallation werden alle Untermodule aufgerufen, die nicht mchr benotigt werden und deshalb dcinstall- 
liert werden konnen. Bei der Installation werden alle Untermodule aufgerufen, die neu installiert werden mussen, oder 
nur upgedated werden sollen. Die Reihenfolge der Installation bzw. Deinstallation wird durch eine Modulprioritat in der 
Modulbeschreibungsdatei festgelegt. 

Bei der Deinstallation und bei der Installation konnen mehrere Neustarts des Betriebssystems durchzufuhren sein, bis 
die gesamte Installation vollstandig abgeschlossen ist. Die Starterkomonente ist dann dafur verantwortlich, daB die In- 
stallation nach einem Neu start des Betriebssystems, der von einem Untermodul benotigt wird, wieder an geeigneter 
S telle fortgesetzt werden kann. 

Das Obermodul muB einen Wartemechanisrnus implementieren, der es ermoglicht ein Untermodul nach dem anderen 
zu installieren und jeweils zu warten, bis das Untermodul seine Installation abgeschlossen hat. 

Der Checker uberpruft, ob die benotigten Voraussetzungen fiir die zu installierenden Untermodule erfullt sind, bei- 
spielsweise ob geniigend Speicherplatz vorhanden ist. Der Checker kann die Installation abbrechen, wenn die Vorausset- 
zungen nicht erfullt sind. Wird mit Benutzerinteraktion gearbeitet, dann gibt der Checker eine entsprechende Fehlermel- 
dung am Bildschirm aus. Wenn ohne Benutzerinteraktion gearbeitet wird, dann schreibt er in die Ergebnisdatei eine ent- 
sprechende Fehlermeldung, wenn dies vom Administrator gewtinscht wird. 

Ein Untermodul wird immer von einem Obermodul zur Installation oder Deinstallation mit dem Aufruf eines Unter- 
moduls aufgerufen. Es besitzt keine Benutzeroberflache und kann deshalb nur im Modus ohne Benutzeroberflache auf- 
gerufen werden. Wird ein Obermodul als Untermodul aufgerufen, dann darf die Benutzeroberflache, die ein Obermodul 
gewohnlich hat, nicht erscheinen und es mussen alle Einstellungen, die fur die Installation wichtig sind aus der Auftrags- 
datei gelesen werden. 

In der Modulbeschreibungsdatei werden die Anforderungen (Speicherplatz, Rechte, . . .) der Installationsmodule vom 
Moduldesigner, so wie die Abhangigkeiten der einzelnen Module voneinander festgehalten. In dieser Datei kann bei 
vollstandig ausgereifter Implementierung auch die Aufrufhierarchie der einzelnen Module geregelt werden. Diese Datei 
darf wahrend des Setups im schreibgeschutzten Bereich liegen Die Auftragsdatei beinhaltet alle Informationen, die den 
Ablauf des gesamten Installationsmoduls steuem. Nicht besetzte Werte sind mit Standardwerten zu belegen. Der Pfad 
zur Auftragsdatei wird dem Setupmodul uber Parameter mitgeteilt. 

Die Statusdatei dient der Kommunikation zwischen Obermodulen und Untermodulen. Informationen die temporar 
vom Obermodul an ein oder mehrere Untermodule bzw. umgekehrt mitgeteilt werden mussen, konnen hier eingetragen 
werden. Diese Datei muB wahrend des Ablaufs der Installation immer schreibbar sein und die Datei sollte im Windows- 
Temp- Verzeichnis abgelegt werden. 

Folgende Eintrage sind definiert 

1 . Reboot und Restart-Meidungen vom Untermodul 

In der Datei Statusdatei wird unter anderem vom Untermodul protokolliert, ob das Obermodul einen Reboot oder Re- 
start des Systems oder dergleichen fur das Untermodul durchzufuhren hat. Das Obermodul sollte immer darauf achten, 
den Neustart fur mehrere Untermodule nur einmal zu machen. 

Nachfolgend sind als Beispiele die Eintrage fur Reboot und Restart in der Statusdatei aufgefuhrt, wobei folgende Keys 
moglich sind. 

Der Eintrag "Reboot = 01 1" wird von einem Modul gemacht. Damit erkennt das Obermodul, daB es einen Reboot 
durchfuhren muB, damit ein Untermodul fertig installiert/deinstalliert werden kann. Wird ein Reboot durchgefuhrt, ist ein 
Restart uberflussig. 
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Der Eintrag "Restart = 011" wird von einem Modul gemacht. Damit erkennt das Obermodul, daB es einen Restart von 
Windows durchfuhren muB, damit ein Untermodul fertig instaUiert/deinstaUiert werden kann. 

2. SetupID des Obermoduls 

Der Eintrag "Sektion = [SetupID]" teilt den Untermodulen mit, von welchem Obersetup sie aufgerufen wurden. 
Stimmt dieselD mit der ID des Moduls in der Registry uberein wird das Modul zur Beschleunigung des Installauonsvor- 
ganges nicht noch einmal neu installiert. Als Key ist mogUch "Date Time = Aktuelles Datum und Zeit". 

10 Ergebnisdatei 

Der Administrator gibt in der Auftragsdatei an, ob und wo die Installationsprogramme bei der Installation ohne Benut- 
zerinteraktion ihre Ergebnisdateien ablegen sollen. Der Administrator gibt dabei nur den Pfad der Ergebmsdatei _ an Der 
Dateiname selbst ist immer der Computername des Rechners, <Computemame>.im. Wird vom Administrator ein Netz- 
laufwerk aneegeben, dann befindet sich nach der Installation von jedem Computer eine IM-Datei in dem angegebenen 
Verzeichnis Uber den Explorer kann dann nach dem Inhalt der Dateien gesucht werden. Wird beispielsweise nach Er- 
ror" gesucht, dann werden alle Dateien aufgelistet. in denen ein Fehler enthalten ist und damit aue Computer bei denen 
eine Installadon fehlerhaft abgelaufen ist. . 

Von den InstaUationsprogrammen darf die Datei nicht bei jedem Schreiben neu angelegt werden, sondem nur e^anzt 
werden Das heiBt vorhandene Sektionen in der Ergebnisdatei mussen erhalten bleiben. Es mussen sowohl gemapple 
Pfade (f:\myRechner\respath <Computername>.ini) als audi IINC Notiemngen <\\MYRechner\respam\<Computerna- 

mo.ini) verwendet werden konnen. . _ . 

In Fig 3 ist ein Teil des Setup- Verfahrens als FluBdiagramm dargesteUt, wobei Fig. 4 eine Fotfsetzung des FluBdia- 
eramms von Fig. 3 ist. Nach dem Start wird zunachst ausgeschlossen, daB ein Downgrade ertolgt 

Als nachstes wird festgestellt, ob ein Zahlerstand in dem Modulcounter vorhanden ist (ist em Modulcounter vorhan- 
den'?-) Wenn ia. wird abgefragl, ob es sich urn eine ersle InsiaUation handell, und, wenn ja, wird eine InsiaUation durch- 
ecfuhrt Wenn festgestellt wird, daB kcin Modulcounter vorhanden ist, wird der Modulcounter auf 1 gesetzt, und cs wird 
ein Uninstallstring und ein Displayname erzeugt, wobei als nachstes wiederum die Frage nach einer ErstinstaUauon ge- 
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Wenn die Frage nach einer ErstinstaUation mit nein beantwortet wird, wird festgestellt, ob ein Aufrut durch e,n ande- 
res Modul erfol|t. Wenn ja, wird gegebenenfalls ein Hag fur den Sharedcounter beibehalten, was aber nur ,n dem noch 
beschriebenen Beispiel in Verbindung mit einer alteren Version von Unwise.exe notwendig ist, und die Installation wird 
dann durchgefiihrt. Wenn die Frage nach dem Aufruf eines anderen Moduls mit nein beantwortet wu-d, wird ^hiedem 
obein UninstaUstring bereits gesetzt wurde, wenn ja, wird ein Upgradeflag gesetzt, u. U. ebentalls ein Flag fur den Sha- 
35 redcounter beibehalten und eine Installation durchgefiihrt. Wenn nein, wird ein Uninstallstring ^^ r ^ a ^ 
ter erhoht u U ebenfalls ein Rag fur den Sharedcounter beibehalten und die Installation durchgefuhrt. Nachdem die Da- 
teien installiert sind. geht das Verfahren am Punkt a (Fig. 3 und 4) in das Verfahren von Fig. 4 uber. 

WurdS Modul bereits einmal installiert (keine ErstinstaUation), dann wird modulintern immer ein Update gefahren, 
d. h. alle zu installierenden Dateien werden neu kopiert. Registry-Eintrage, die einen Update uberleben mussen, durten 

40 ^SLTuSe^d^Module (Untermodule, gemeinsame Komponenten) erfolgt gemaB Fig. 4. Es wird zunachst ge- 
pruft ob andere Module aufgerufen werden sollen. Dies ist entweder fest voigegeben durch eine starre Imp ementierung 
Oder das Modul erkennt dies aus einer Modulbeschreibungsdatei oder anhand eines bereits bestehenden Chenteintrages. 
Wenn ja wkd als nachstes uberpriift, ob das Untermodul bereits durch das gerade ablaufende Modul installiert wurde 
was durch einen Clienteintrag erkannt werden kann. Wenn nein, wird der Modulcounter des Untermoduls un, den Wert 
des e£nen Modulcounters erhoht und das Updateflag wird geloscht. Wenn ja, wird festgestellt, ob em Update durchge- 
fUto werden soU, was durch das Updateflag erkannt wird. Dies wird beispielsweise beim Kommandozeilenparameter/ 

UP We a nnfeFmge nach dem Upgrade mit nein beantwortet wird, wird der Modulcounter des Untermoduls erhoht. Wenn 
die^rage nachdem Upgrade mit ja beantwortet wird, wird das Modul zum Upgrade aufgeruten und die entsprechende 
InstSfon durchgefuta. Nachdem der Modulcounter des Untermoduls auf den neuesten Stand gebracht wurie Wttd 
das Untermodul als Client eingetragen und die Deinstallationsroutine vermerkt, worauf das Modul zur InstaUahon aut- 
gerufen Xd Am Ende dieser Routine wird wieder am Anfang weiterverfahren, wenn noch weitere Module aufgerufen 
werden mussen Wenn alle Module aufgerufen sind, endet das Verfahren. 

S 5 zei^das Ablaufdiagramm fur die DeinstaUation der Module. Zunachst wird festgestellt, 0* .andere Module ; auf- 
eerufen warden soUen. Wenn ja, werden die Module zur DeinstaUation aufgerufen und es wird emschieden, ob der Client 
fdafuntemSil) noch einen Zahlerstand im Modulcounter hat. Wenn ja, kehrt die Routine .zum Ausgangspunkt zu^ck 
^nn neL wird aer CUentvermerk des Untermoduls geloscht und die Routine kehrt zum Ausgangspunkt zuruck. Wenn 
ke'n welte^Modul aufgerufen werden muB, wird festgestellt, ob der Modulcounter gleich "1 ist Wenn nein wird der 
M^coumerum " 1 " erniedrigt, und bei der nachsten Frage wird entschieden, ob die Demsta.lation uber den Umnstall- 
sSng Srnfen wurde. Wenn ja, wird der UninstaUstring vernichtet, und das Verfahren ist abgeschlossen, wenn nein, 

iSt ^^:m^^TcZoun«r ungleich 1 ist, wird festgestellt, ob es einen Zahlerstand in einern Sto, 
red^Zer gfbt ^ una, wenn ja, wird festgestellt. ob der Sharedcounter der Datei (z. B. Exe) = 1 ist. Wenn nein, ertolgt _«ne 
normal" Delnillation bei der die Dateien geloscht und dadurch deren Sharedcounter emiedngt wird. Danach wird das 
VerfaSe ^vor der Entecheidung uber die DeLtallation iiber den UninstaUstring fortgesetzt. Wenn bei der 
ob^nen Sharedcounter gibt und ob der Sharedcounter der Datei (z. B. Exe) = 1 ist, mit nein bzw ja beantwortet wud 
warden die Dateien deinstalliert und aUe Eintrage vernichtet, und es darf kein Reboot fur Inuse-F.les ertolgen, und das 
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Verfahren wird vor der Entscheidung uber die Deinstallation uber den Uninstallstring fortgesetzt. 

Dateien deinstallieren und alles putzen bedeutet, daB alle Eintrage geloscht werden, die jemals von diesem Modul er- 
zeugt wurden, inklusive des Uninstallsti-ings. Sind Inuse-Dateien vorhanden, dann werden alle Eintrage geloscht, die zu 
diesem Inuse ruhrten und die Dateien werden zur Delete-Liste des Betriebssys terns hinzugefugt, damit diese nach einem 
Reboot geloscht werden. 

"Normale" Deinstallation bedeutet, daB so deinstalliert wird, wie es bisher in einem noch nicht modularen Verfahren 
ublich war. Der Sharedcounter wird erniedrigt, notwendige Dateien zur Kompatibilitat mit alten Installationen konnen 
zuriickbleiben. Sind Inuse-Dateien vorhanden, dann werden alle Eintrage geloscht, die zu diesem Inuse ruhrten, und die 
Dateien werden zur Delete-Liste hinzugefuhrt, damit diese nach einem Reboot geloscht werden. Damit kann ein Uber- 
gang von einem nicht modularen Verfahren auf das modulare Setup- Verfahren erfolgen. 

Damit das Installationsmodul entscheiden kann, was zu tun ist, mussen folgende Kommandozeilenparameter ausge- 
wertet werden: 

7S" gibt. an, daB die Installation ohne Benutzerinterakt.ion im Netzinstallationsmodus durchgefuhrt. werden soil. Die 
Auftragsdatei muB vorhanden sein. 

"/Install" gibt an, daB das Installationsmodul installiert werden soli. 
"/Remove" gibt an, daB'das Installationsmodul deinstalliert werden soli. 

"/Upgrade" gibt an, daB ein Upgrade durchgefuhrt wird. Werden weitere Untermoduie aufgerufen, so mussen diese 
ebenfalls mit dem Schalter /Upgrade aufgerufen werden. Werden vom Installadonsmodul keine Untermoduie aufgeru- 
fen, dann muB diese r Parameter nicht ausgewertet werden. 

"/Launcher" gibt an, daB das Installationsmodul vom einem anderen Installationsmodul aufgerufen wurde. Wird vom 
Installationsmodul ein Neustart benotigt (Neustarts sind nur am Ende der Installation moglich!), so ist in der Auftrags- 
datei das Flag "Reboot" oder das Rag "Restart" in der Sektion [SNINSTAL] auf 1 zu setzen. Der Aufrufer des Moduls 
hat fur den abschlieBenden Neustart zu sorgen (evtL fur mehrere Module gemeinsam). Wurde ein Installationsmodul 
ohne diesen Parameter aufgerufen, so ist es das oberste Installationsmodul der Hierarchic 

"/Admin" gibt an, daB das Installationsmodul nur die Obernache anzeigen darf und alle Einstellungen in eine Auf- 
tragsdatei schreibt. Es wird keine Installation ausgeftihrt und das Installation sprograiiun wird nach der Benuzterinierak- 
tion bccndct. Damit kann das InstaUationsprogramm als cine Art Wizard zum Erstcllcn der Auftragsdatei fur den Netz- 
installationsmodus verwendet werden. 

"/Path <Pfad der Auftragsdatei>" gibt den Pfad an, in dem die Auftragsdatei zu finden ist, das heiBt von wo gelesen 
(Netzinstallationsmodus) oder wohin (Administratormodus) geschrieben werden soli. Als Standardeinstellung wird die 
Auftragsdatei im dem Verzeichnis gesucht/erstellt, in dem das Installationsprogramm gestartet wurde. 

"/Debug" startet das Installationsmodul im Debugmodus (Kann immer mit angegeben werden) und schreibt eine Text- 
datei mit dem Nanien <Modulname>.txt in das' Verzeichnis <Windir>Debug. AuBerdem wird auf jeden Fall ein Result- 
file in das selbe Verzeichnis ausgegeben. 

Moglichkeiten der Installation: 

Die folgende Tabelle beschreibt, welche Kommandozeilenparameter miteinander in Kombination auftreten diirfen. 





/s 


/Install 


/Remove 


/Upgrade 


/Launcher 


/Admin 


/Path= 
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/Install 
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X 
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/Remove 


X 




X 
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/Upgrade 


X 






X 
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o 


/Launcher 


X 


x/-/- 


-M- 


-/-/X 


X 




o 


/Admin 












X 
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/Path= 


x/x/x/- 


x/-/-/- 


-IxJ-l- 


-1-1%}- 


o/o/o/- 


-/-/-/x 


X 



Die Tabelle wird zeilenweise betrachtet, es mussen alle Bedingungen erfullt sein. Die linke Spalte entspricht der Aus- 
gangsposition, jede andere Spalte entspricht der zusatzlichen Auswahl. x bedeutet die Parameter mussen gemeinsam auf- 
treten, - bedeutet die Parameter diirfen nicht gemeinsam auftreten, o bedeutet der Parameter ist optional, das heiBt er 
kann in der Kombination auftreten, muB aber nicht. 



Sonderfall 

- /Install, /Remove und /Upgrade mussen mit /S auftreten, diirfen aber nicht gemeinsam auftreten und /S darf auch 
nicht ohne einen weiteren Parameter sein. 

- Wird /Remove angegeben, dann wird keine Steuerdatei benotigt. 
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- /S (Zeile) braucht entwcder /Install, /Remove oder /Upgrade (Spake) 

- /Install (Zeile) braucht /S (Spalte) aber auf keinen Fall /Remove oder /Upgrade(Spalte). 

" %2F£S ^S^^SS^ /S (Spalte) und entweder /Install (Spalte), ^(*ff) 
' ^p"^^bcSS vorhanden sein und kern /Admin (Spalte) oder kern IS (Spalte), kern /Install (Spalte), kern 
/Remove r^nalte^ kein /Upgrade, kein /Launcher (Spalte), aber /Admin (Spalte). 

SSfl K Sundrtall die A.lttaWai » ln S .«U>lio„s».™ich„i s ge! uchU 8 es c toeb e „ w«d. 

eSs Up^es ve^twortUch. Untermodule werden mit dem Schalter /Upgrade autgeruten, wenn nur exn Upgrade 

?,S»£7stal D™ McSulgenB, gihiwchl IB, da. In«.U.uo„s. .La »uch fu, das DainsiaU.uo^ogr™. 
-• pHpnP wUe-Dateien werden in beiden Teilen des Modulgeriistes benotigt. 

wf^SatSeS dTe^VMS enden sind modulspezifiscb und miissen vom Entwickler des "^TefSe 

dHT™te Sogik der Ablaufplane. Das Modulgerusl muB famner so allgeu.e.n gehallen werden, daB s.ch daiml aUe Ar 
""pTd,^^^^ ModulgerUs.es e.ne Vxelzabl von Va.aMen fur die in 

temrLoSk Amende wird, die unter Umstanden nicht uberschrieben werden durfen. Es muB unbeding geachW 
Sen daB ^Variablen, auf die nur lesend zugegriffen werden darf wirldich mcht schre.bend zugegnffen word, wed 

eluded werden S>er diese Datei werden die Eigenschaften des InstaUationsprogrammes emgestellt, d,e dann rur aUe 

V^lnZlT^^n Ablauf und die lunktionalitat des Installationsmoduls. D.ese Date, rst modulspez.fisch 
Un DiTD^ DvSid^ D wse bereitet die Installation vor, und innerhalb diese Skriptes werden wichdge Variablen initia- 

'TT'^S^T^Z'^ITa'^ awiachan dan, M daMa», da, V^.bW u„d da„ 

„ht d-„ *»d diaae. Step, nich, .bgcb.Ua, Dks. D«a, ,s, ™«*«,f»ch u„d 

™8 »gap>81 ^ t % YP _ D w „ „,„, atseproft, „b bsreils eii LkenzschlUssel in de,Regisu, tw d« aktuell *u in- 

km dieae, im ggj**. ^fSbgepS. ob de, eingegebena Liaenzschlusael gCMg iab W 0 ,de ein gliluge, Sctlb- 
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die Installation ohne Benutzerinterakuon aufgerufen, dann wird diese Skript abgearbeitet. Was bei der Installation mit 
Benutzeroberflache vom Benutzer eingegeben wird, wird teilweise in dieser Datei aus der Auftragsdatei gelesen. Diese 
Datei gehort zura Modulgerust und darf nicht verandert werden. 

Die Datei InstSilent_MS.wse ist die modulspezifische Erweiterung zu InstSilent.wse. Wird die Installation ohne Be- 
nutzerinteraktion aufgerufen, dann wird dieses Skript abgearbeitet. Was bei der Installation mit Benutzeroberflache vom 5 
Benutzer eingegeben wird, sollte in dieser Datei aus der Auftragsdatei gelesen werden, wenn es nicht bereits durch Inst- 
Silent.wse erledigt wird. Zudem konnen hier noch spezielle Aktionen ausgefuhrt werden. Diese Datei ist modulspezi- 
fisch und muB angepaBt werden. 

In der Datei DVModuls.wse werden alle Untermodule aufgerufen und installiert, die tiber die Moduldefinitionsdatei 
angegeben werden. Diese Dated gehort zum Modulgerust und darf nicht verandert werden. to 

In der Datei InstModuls_MS.wse werden alle Untermodule angegeben, die nicht uber die Moduldefinitionsdatei in- 
stalliert werden konnen und immer installiert werden sollen. Sollen keine Untermodule installiert werden, so muB diese 
Datei leer sein. Diese Datei ist modulspezifisch und muR angepaGt werden. 

Das Skript CheckModuls.wse uberpruft ob ein angegebenes Modul vorhanden ist und installiert werden kann. Wurde 
das Modul nicht gefunden, so wird die Installation abgebrochen und das System wieder zuriickgesetzt. Diese Datei ge- 15 
hort zum Modulgerust und darf nicht verandert werden. 

Die Datei InstModuls.wse ruft alle angegebenen Module als Untermodule auf und installiert diese nach dem Ablauf- 
plan. Diese Datei gehort zum Modulgerust und darf nicht verandert werden. 

In der Datei Inst_MS.wse wird die eigentliche Installation durchgefuhrt. Alle Dateien die kopiert werden sollen, alle 
Registry eintr age die angelegt werden sollen werden hier angegeben. Wird das Installationsskript zu gro8, kann es vom 20 
Enrwickler des Installationsprogrammes in mehrere Include-Skripte unterteilt werden. Diese Datei ist modulspezifisch 
und muB angepaBt werden. 

In der Datei D VFinish.wse werden die abschlieBenden Aufgaben der Installation erledigt. Diese Datei gehort zum Mo- 
dulgerust und darf nicht verandert werden. 

Die Datei Unlnst.wse ist das Hauptskript fur das Deinstallationsprogramm, von dem aus alle anderen Wise-Dateien in- 25 
eluded werden. Uber diese Datei werden die Eigenschaflen des Deinstalladonsprograiinnes eingeslellL, die dann fiir alle 
Module gcltcn. Diese Datei gehort zum Modulgerust und darf nicht verandert werden. 

In der Datei UnInstModuls_MS.wse werden die installierten Deinstallationsprogramme der Untermodule zur Dein- 
stallation aufgerufen. Diese Datei ist modulspezifisch und muB angepaBt werden. 

In der Datei UnInstDel_MS.wse wird die eigentliche Deinstallation durchgefuhrt, d. h. hier wird z. B. die Install.log 30 
aufgerufen und es wird alles geloscht, was nicht uber die Install.log geloscht werden kann. Diese Datei ist modulspezi- 
fisch und muB angepaBt werden. 

Patentanspriiche 

35 

1 . Setup- Verfahren zum Installieren und Deinstallieren von Software-Produkten oder -produktfamilien, die wenig- 
stens eine Komponente gemeinsam nutzen, wobei die gemeinsame Komponente bei der Installation der Produkte 
installiert oder einem Update unterworfen und bei der Deinstallation deinstalliert wird, wenn sie nicht mehr benotigt 
wird, dadurch gekennzeiclinet, daB das Setup- Verfahren durch Module ausgefuhrt wird, die nacheinander aufge- 
rufen und abgearbeitet werden, und daB die gerneinsamen Komponenten als eigenstandige Module innerhalb des 40 
Setup- Verfahrens ausgefuhrt werden und dazu ein eigenes Installationsprogramm und Deinstalladonsprogramm 
ausfuhren. 

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daB in der gerneinsamen Komponente festgestellt und ge- 
speichert wird, wie oft sie von anderen Setup-Programrnen zur Installation bzw. Deinstallation aufgerufen wurde, 
und daB die gemeinsame Komponente dann automatisch deinstalliert wird, wenn sie von der letzten Produktinstal- 45 
lation zur Deinstallation aufgerufen wird, die die gemeinsame Komponente noch benutzt hat. 

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daB die Module in eine Hierarchie aus wenigstens 
einem Obermodul mit Benutzeroberflache und Unterrnodulen ohne Benutzeroberflache eingegliedert werden und 
daB die Module entsprechend der Hierarchie abgearbeitet werden. 

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, daB beim Hinzufugen eines neuen Obermoduls ein bishe- 50 
riges Obermodul als Untermodul aufgerufen wird. 

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daB das neue Obermodul die gesamte Benutzeroberflache 
beinhaltet. 

6. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, daB die Hierarchie bzw. die 
Aufrufreihenfolge in einer Anweisungstabelle festgehalten wird. 55 

7. Verfahren nach Anspruch 6, dadurch gekennzeichnet, daB die Anweisungstabelle auBerhalb der Module angelegt 
wird. 

8. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daB beim Start einer Installation gepruft wird, ob 
ein Zahlerstand in einem Modulcounter vorhanden ist, daB, wenn kein Zahlerstand im Modulcounter vorhanden ist, 
und es sich damit. um eine Neuin stall ation handelt, der Zahlerstand auf 1 gesetzt, ein Uninstallstring gesetzt und ein 60 
Displayname erzeugt wird, daB, wenn ein Zahlerstand im Modulcounter vorhanden ist, ein Uninstallstring erzeugt 
und der Zahlerstand des Modulcounters erhoht wird, wenn das Modul zum ersten Mai als Obermodul aufgerufen 
wurde, und daB dann die Installation der gerneinsamen Komponente durchgefuhrt wird. 

9. Verfahren nach einem der Anspruche 1, 2 oder 8, dadurch gekennzeichnet, daB, wenn nach der Installation der 
gerneinsamen Komponente eine weitere gemeinsame Komponente in Form eines Untermoduls installiert wird, ge- 65 
pruft wird. ob der Untermodul bereits installiert war, daB, wenn der Untermodul bereits installiert war und kein Up- 
date vorliegt, der Zahlerstand des Modulcounters des Untermoduls erhoht, der Untermodul als Client eingetragen, 

die DeinstaUationsrouline vermerkt und die Installation des Untermoduls durchgefuhrt wird, und daB, wenn der IJn- 
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termodul noch nicht installiert war, der Zahlerstand des Modulcounters des Untermoduls um den Wert des eigenen 
Modulcounters erhoht, das Update-Flag geloscht, der Untermodul als Client eingetragen, die Deinstallationsroutine 
vermerkt und die Installation des Untermoduls durchgeruhrt wird. 

10. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daB bei der Deinstallation gepnift wird, ob ein an- 
derer Modul aufgerufen werden soli, daB, wenn ja, die Module zur Deinstallauon aufgerufen werden, daB, wenn im 
Client noch ein Zahlerstand im Modulcounter vorhanden ist, mit der Deinstallation fortgefahren und u. U. ein wei- 
terer Modul aufgerufen wird, und daB, wenn im Client kein Zahlerstand mehr im Modulcounter vorhanden ist, der 
Clientvermerk geloscht und die Deinstallauonsrountine fortgesetzt wird. 

11. Verfahren nach einem der vorhergehenden Anspruche, dadurch gekennzeichnet, daB, wenn der Zahlerstand in 
dem Modulcounter gleich "1" ist, gepnift wird, ob es einen Zahlerstand im dem Sharedcounter gibt, daB, wenn ja, 
eine Deinstallation durchgeruhrt wird, die Files geloscht werden und der Sharedcounter erniedrigt wird, daB, wenn 
nein, alle Dateien deinstalliert und alle Eintrage geloscht werden, und das Modul deinstalliert wird und daB, wenn 
der Zahlerstand in dem Modulcounter ungleich "1" ist, der Zahlerstand im Modulcounter nur um "1" erniedrigt. 
wird. 
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